![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Oracle Performance Tuning and Optimization
What To Test in the RDBMSTo verify the performance of a batch processing system, the RDBMS should be tested to verify the load, processing, and unload times. Although a batch processing system does not have to perform with a strict response time criteria, often the maximum run time of the job is specified. To verify that you can meet this criteria, you should use a database that is close in size to the production database. Once you have built an effective load test with repeatable performance results, start changing some of the parameters described in Part II of this book and earlier in this chapter. By changing only one parameter at a time, it is easier to see which changes have affected the performance. Before changing anything, set your expectations for the changes you are going to make. If the results dont turn out as expected, try to understand why they didnt. Be sure to log the results so that you have a reference of what changes were effective and what changes were not. What To Test in the OSFor the most part, the OS is tested with the RDBMS. If you have to change some specific OS parameter to increase a limitation, you usually dont have to retest the performance. Any limit change is usually associated with an RDBMS change, and the two can be tested together. Other OS changes such as feature enhancements should be tested with the RDBMS, but you should more closely watch and analyze these results. You should carefully analyze things such as scheduler changes and cache affinity that may have an adverse affect on the system to verify that performance has not degraded. As stated earlier in this book, the OS is primarily a vehicle for the RDBMS to use. The primary goal in tuning the server OS is to reduce overhead and optimize the I/O, memory, and networking subsystems. BenchmarksStandardized benchmarks are a good way to judge how well a system is performing and to compare different hardware platforms. If they are available to you, standardized benchmarks are also a good way to analyze the performance of your particular platform. The TPC-C benchmark is an OLTP benchmark; the TPC-D benchmark is a strictly decision support benchmark. Batch processing systems require parts of both of these benchmarks. By looking at TPC benchmarks submitted for the platforms in which you are interested, you may be able to make some comparisons. Base your comparisons on a combination of the TPC-C and TPC-D benchmarks. Examine the Full Disclosure Report (FDR) submitted for a TPC-D benchmark by the test sponsor; look for a breakdown of performance based on query type. Look for the performances for the particular query types you use in your operation. This information may give you an indication of how well the testing configuration would work in your environment. The TPC-C benchmark can give you an idea of how general OLTP processing performs on that platform. By looking at both of these benchmarks, you can get an idea of the performance of both the OLTP and DSS systems. Because batch jobs have some of the characteristics of both of these systems, these results may be of some value. A system tuned for benchmarks such as the TPC-C and TPC-D benchmarks may provide useful tuning hints. Because the primary goal of a TPC benchmark is for the sponsor to get the best possible performance, you can see how the sponsors have optimally tuned their systems. Because official TPC-C and TPC-D benchmarks using Oracle are usually submitted by the hardware manufacturers, OS vendors, and Oracle, you can be assured that the system has been tuned as optimally as possible. If you can, obtain a Full Disclosure Report from the TPC (on the Web at this URL: http://www.tpc.org); look at the way the system was designed and tuned. Of course, the best benchmark to use on your batch processing system is one of your own batch processing jobs. This benchmark provides you with all the information you need to judge the amount and size of the hardware required. Such a customized benchmark also can provide you with valuable information about any configuration changes you make. SummaryThis chapter looked at some of the attributes of a batch processing system, explained how to analyze the characteristics of such a system, and suggested how to design an optimal configuration based on those attributes. A batch processing system is different from OLTP and decision support systems but has some of the characteristics of both of them. A batch system typically involves loading data, processing that data, and unloading the results of the transactions. Batch processing systems are different from OLTP systems in that batch jobs are not run interactively; they are submitted at some later time (perhaps much later) and run until completion. The characterization of the batch processing system in this chapter is generalized because batch processing systems vary in so many different ways. By looking at the attributes of your own system, you can better determine which of the tuning tips in this chapter will work for you and which will not. The types of queries used in your batch processing system may be more representative of OLTP queries, be more like DSS queries, or may be something completely different. What is important is that you look at the queries themselves and examine the data access patterns; from that analysis, determine how your system can best be designed. I am a big fan of the Oracle Parallel Query option (as you may have ascertained from my comments in this and other chapters). I believe that you will find a significant performance boost with the Parallel Query option if you have long-running, complex queriesespecially those that involve table scansa well-designed I/O subsystem, and a disk array. Frequently, a batch processing system is used to run the same job over and over again with new data. This can be advantageous because it allows you to try new tuning parameters and be innovative. By having essentially the same job to run, you can quantitatively measure the results of the changes you make and determine whether performance has changed (either positively or negatively). By logging the results of these tests, you can gather valuable data that can help determine which changes you should try in the future.
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. |